Das nächste Verfahren, das wir uns anschauen wollen, ist SPN, Shortest Process Next. Das ist ein probabilistisches Verfahren.

Das basiert darauf, Zeitreihen zu bilden, diese zu analysieren und dann entsprechend für die Prozessorzuteilung, für die CPU-Zeitung zu verwerten.

Zeitreihen beziehen sich auf die CPU-Stoßlänge und man versucht mit SPN eigentlich das so ein Stück weit zu machen, was wir im Vorfeld schon bei Virtual Robbing gesehen haben, wo man dann versucht, eben Prozesse, die interaktiv sind, mit kurzen CPU-Stoßlängen bevorzugt zu betrachten.

Das versucht man mit SPN entsprechend auch zu machen, aber eben analytisch und nicht strukturell.

Hier ist es so, dass mit SPN jeder Prozess entsprechend der für ihn im Durchschnitt berechneten oder erwarteten Bendingzeit eingeplant wird.

Wir müssen also die Betienzeit zum Zeitpunkt der Einplanung von solch einem Prozess kennen.

Das braucht Vorabwissen letztendlich über die Prozesslaufzeiten.

Wo bekommen wir denn so ein Wissen her?

Wenn wir zum Beispiel einen Stapelbetrieb haben, dann könnte man einfach hingehen und sagen, die Fristen, die man den Batchjobs sozusagen zuordnet, Timelapse, könnten so ein Sortierkriterium sein.

Wenn wir den Produktionsbetrieb betrachten, also die haben wir praktisch im Betriebssystem gebaut, konfiguriert und wir haben bestimmte Test-Anwendungsszenarien, die wir laufen lassen können.

Die messen wir durch und bilden Statistiken über diese Probeläufe und kommen so an die Information der erwarteten Bedienzeit für die jeweiligen Prozesse heran.

Oder wir haben Dialogbetrieb, lassen das System wirklich laufen, messen im normalen Betrieb die Rechenstoßlängen und bilden Mittelwerte davon,

um dann nach einer Abschätzung für einen zukünftigen Rechenstoß dann praktisch abgeben zu können.

Das sind so die typischen Herangehensweisen, die man hat.

Man basiert auf einer sortierten Bereitliste, die eben nach den Laufzeiten der einzelnen Prozesse, denn halt sortiert ist und zwar aufsteigen vorne sind die Kürzeren, hinten sind dann die Längeren.

Das heißt also, das ist durchaus eine komplexere Warteschlangenoperation durchzuführen, insbesondere zum Einfügen der laufbereiten Prozesse,

wo man denn schon darauf achten muss, inwiefern denn sozusagen dieses Sortierverfahren denn es skaliert.

Die Auswahl des nächsten Prozesses ist eigentlich immer einfach. Da geht man vorne ran an die Liste und nimmt die Nächsten runter, wenn man ja weiß, man hat den aufsteigend sortiert eingesetzt.

Nun statisch oder dynamisch wird die Laufzeit dann halt abgeschätzt.

Man kann denn sagen, dass Stapelbetrieb und Produktionsbetrieb jetzt hier zwei Ansätze sind, um praktisch eine statische Abschätzung denn für diese Prozesse,

für die erwarteten Prozesslaufzeiten zu geben, wohin ging im Dialogbetrieb, denn eher praktisch diese dynamische Abschätzung zur Laufzeit dann wirklich stattfindet.

Nun, indem wir die Antwortzeiten verkürzen, sind wir durchaus in der Lage, die Gesamtleistung in so einem System zu stärken,

insbesondere eben auch den Einausgabedurchsatz, indem wir ja praktisch interaktive Prozesse,

so man denn glaubt, dass die Prozesse mit der kürzeren Laufzeit eben interaktiver sind, als die mit der längeren Laufzeit bevorzugen würde.

Das heißt aber auch, dass die Prozesse, die hier länger laufen, die benachteiligt werden, eben verhungern können.

Es kann durchaus Situationen geben, wo die Prozesse eben nach einer sehr, sehr langen Zeit die CPU erst zugeteilt bekommen.

Und da reden wir hier bei sehr lang, nicht nur um Millisekunden, Sekunden, das könnten durchaus Stunden sein,

wenn nicht so ja noch länger in Abhängigkeit davon, wie denn dieses Rechensystem,

wo denn letztendlich so ein SPN-Verfahren drin realisiert ist, denn eigentlich genutzt wird.

Einen Konvoieffekt haben wir jetzt hier eigentlich nicht, weil wir ja immer die interaktiven Prozesse damit bevorzugen können.

Man muss aber schon sehen, dass praktisch diese Abschätzungsvorgänge, die man hier durchführt,

die Probabilistik, die man eben einsetzt, eben nur eine näherungsweise Lösung ermöglicht.

Wir werden nie exakt im Voraus diese Rechenstoßlängen für solche Prozesse bestimmen.

Damit ist sozusagen die obere Grenze von solchen Stößen, von den CPU-Stößen eben sehr selten exakt vorhersagbar.

Man kann die eben nur abschätzen im Endeffekt.

Die Mittlung, die man denn durchführt, ist mal hier so ein bisschen dargestellt.

Das heuristische Verfahren nutzt einfach Mittelwertbildung über die sozusagen gemessenen Rechenstoßlängen, die wir da halt haben.

Das ist eine einfache Formel, wie sie halt hier dargestellt ist, um das arithmetische Mittel letztendlich zu bilden.

Die TI's sind die einzelnen Rechenstoßlängen der Prozesse.

Hier steht für Task sozusagen, man stelle sich also mal vor, das sind die einzelnen Aufgaben, die die Prozesse jetzt durchführen würden.

Und alle diese Stöße, die der Prozess dann halt macht, die werden dann sozusagen summiert.

Und dann halt die Entstöße werden dann durch eine Teilthermatik gemittelt.

Das würde man für jeden einzelnen Prozess machen, um dann sozusagen den Mittelwert dieser Rechenstoßlänge eines Prozesses dann entsprechend bestimmen zu können.

Und das Problem dieser eigentlich immer noch einfachen Formel ist die Tatsache, dass hier alle Stöße eines Prozesses gleichgewichtet sind.

Wenn man sich aber die Realität von Programmerabläufen anschaut, dann wird man eher so sehen, dass so die jüngeren Aktivitäten von Programmen viel wichtiger sind als die Aktivitäten, die so ein Prozess vielleicht mal vor Minuten durchgeführt hat.

Das heißt, die Lokalität eines Prozesses ist durchaus wichtig und die geht jetzt hier in der einfachen Mittelwertbildung nicht ein.

Man sollte hingehen und den jüngeren Rechenstößen eine größere Wichtung geben als den älteren Rechenstößen.

Das sehen wir dann auf der nächsten Folie, wie man sowas dann typischerweise macht.

Nun, wie kommen wir jetzt praktisch an so eine Rechenstoßlänge ran?

Wir müssen die Dauer des Rechenstoßes sozusagen messen.